1. Field of the Invention
The present invention relates to program flow control in computer systems, and in particular to a method for running application programs on a computer system having an operating system, supporting threads, semaphore mechanisms and long-jumps, wherein said operating system does not support context processing due to the lack of a mechanism to access the central processing unit (CPU) state.
2. Description and Disadvantages of Prior Art
The general purpose computer, a finite approximation of the universal Turing machine, maintains state only in a finite set of transistors and optionally in a limited magnetic storage. A specific portion of the state of a program running within a computer is defined herein a context as used in prior art terminology. A context may be regarded as a snapshot of the runtime flow of a program as seen by the CPU. In large, this snapshot contains the set of CPU computational registers, the instruction pointer, a record of the execution path of the program, ie the invocation stack and the possibly separate but associated automatic storage and function call parameters residing along the execution path, ie the parameter stack. A context does not encapsulate memory allocated from heap and does not maintain a copy of the static storage used in runtime of the application program.
Maintaining multiple contexts is useful for programs wishing to sustain multiple concurrent runtime states but where only one state is active at a time. Discrete simulation is a typical example; modeled entities might maintain state by running as separate computational tasks. In this case in prior art computer systems supporting context processing a simulation manager orchestrates, which entity performs each discrete simulation step. After each step, the entity returns control to the manager.
For example, on UNIX platforms, so-called “u-context” functions are provided as part of the operating system. Such u-context functions may be seen herein as a standard Application Programming Interface (API) for storing and restoring a program's runtime context. Any reference thereto is to be understood broadly and shall include also implementations other than UNIX.
The API set consists of four functions. All functions operate on a structure defined as ucontext_t. The information in ucontext_t is sufficient for restoring the CPU to a precise program execution state. In alphabetical order:                getcontext( )—takes a snapshot of the current computing state. The context can be used to return exactly to “this” point in the program at a later time.        makecontext( )—builds a new context, or modifies an existing one such that when the context is activated, a specified function will be invoked.        setcontext( )—takes as input a context built with either getcontext( ) or makecontext( ) and switches the CPU to start executing in that context        swapcontext( )—basically a getcontext( ) in the currently running context, followed a setcontext( ) to another context.        
In general, the need to keep multiple program flows active and interacting with one-another while each flow is independent is best satisfied in prior art by the use of “context processing”. Prior art contexts also provide a basic infrastructure needed for co-operative multitasking. One prior art approach to task orchestration is to rely on a sort of context-to-context messaging to provide the context switch triggering events.
Disadvantageously, in many business environments there are many platforms in use that do not support context processing while applications increasingly require the ability to process multiple contexts. The basic structure of the prior art thread-based program control is depicted in FIG. 1. A runtime version of an application program depicted left in FIG. 1 comprises exemplarily a number of three tasks 12A, 12B, 12C. Each task is executed in a respective thread 14A, 14B 14C. At the end of the thread run, which flows in a direction from bottom to top as indicated by the arrow, a respective semaphore mechanism 16A, 16B, 16C indicates the end of the thread to the CPU 18. The application itself must control the sequence of the threads, e.g. by prior art semaphore mechanisms.
Generally, such environments are platforms in which the operating system does not offer any instruction which enables updating the CPU state as described above. Examples for such platforms are the IBM iSeries server, which is used in enterprises successfully since more than 15 years, further, platforms, on which interpretive languages run, on which platform-independent languages like Java run.
A prior art approach discloses a mechanism to swap contexts between threads. Disadvantageously, this prior art approach does not offer full context compatibility, as it does not provide a “setcontext” and “getcontext” capability.